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10 La presente invention concerne un precede et un dispositif de 

communication d'information. 

Elle s'applique, en particulier, & un reseau a commutation 
asynchrone de paquets, permettant notamment d'interconnecter un petit nombre 
d'equipements multimedia, tout en leur foumissant differentes qualites de service 
1 5 pour echanger des donnees. 

Le comportement d'un trafic de donnees g6nere par un 6quipement 
multimedia (ou application) peut s'inscrire dans deux classes de service 
principales, elles memes divisees, chacune, en deux sous-classes. Ainsi le trafic 
peut etre soit elastique (il s'adapte facilement aux changements de conditions de 

20 transmission), soit temps reel. S'il est elastique, il peut soit etre de nature 
interactive, et done sensible au delai de transfert, soit correspondre & un transfert 
massif d'un gros volume de donnees et done sensible a la bande passante. S'il 
s'agit d'un trafic temps reel, soit il est acceptable de perdre certains paquets 
d'information pour privil6gier le delai de transmission, le trafic est alors appele 

25 "deterministe", soit il est pr6ferable de disposer d'un debit moyen mais sans perte 
de donnees, le trafic est alors appel6 "garanti". 

Le trafic elastique correspond au trafic de type datagramme. Ce 
trafic est dit elastique car il est capable de s'adapter aux conditions de 
transmission sans pour autant perdre de son utility. Un transfert de fichier pourra 
30 aussi bien s'executer via un chemin supportant un d6bit de 64 kilobit par seconde 
que via un chemin supportant un debit de 2 Megabit par seconde. Pour le trafic 
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eiastique, une premiere classe de base concerne le trafic genere par les 
applications interactives ou transactionnelles (comme une application de type 
client-serveur), et une seconde classe identifie les donnees vehiculees par bloc 
(comme le transfert de fichiers). 

5 Les 6quipements generateurs d'un trafic temps r6el requierent un 

service deterministe ou garanti. Pour le trafic deterministe, qui privilegie le respect 
d'une contrainte elevee en ce qui concerne le delai de transmission, I'application 
qualifie la bande passante dont elle suppose avoir besoin, ainsi que le d6lai 
maximal de transmission qu'elle peut accepter. Le reseau privilegie ce type de 
10 trafic mais se debarrasse des donnees pour lesquelles le delai ne peut etre 
respecte. II s'agit par exemple de transmission video (en cas de problemes de 
transmission, une image statique apparaTt), ou de systemes audio de qualite 
moyenne. 

Le sen/ice dit garanti se dtfferencie du service deterministe par le fait 
15 que le reseau ne se debarrasse pas volontairement des donnees issues d'un 
trafic garanti mais que celui ci peut etre affecte d'un delai de transmission variable 
en fonction du trafic deterministe plus prioritaire ou au trafic garanti concurrent. II 
s'agit, par exemple, du trafic video haute definition (utilisant des techniques de 
compression). Dans ce cas, le reseau reserve la bande passante a Papplication 
20 qui requiert un service garanti, mais pour gerer les problemes de gigue (en 
anglais "jitter") sur les donnees a la reception, Papplication doit poss6der des 
capacites de stockage temporaires des donnees (de I'ordre de la seconde de 
trafic), afin de retablir le comportement original du trafic. 

La garantie de la qualite de service exigee par des applications 
25 concurrentes et de natures differentes passe par la resolution de problemes tels 
que la gestion des ressources et le controle de trafic. Les proc6des £ mettre en 
oeuvre doivent permettre au reseau de fonctionner de fa9on optimale tout en 
foumissant une qualite de service acceptable aux differentes applications. Ce 
probleme a fait Pobjet de nombreuses 6tudes pour les r£seaux a commutation de 
30 circuits et pour les r6seaux § commutation de paquets. 
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Dans les reseaux a commutations de circuits, la solution connue 
consiste a allouer a chaque connexion une bande passante constante (canal) 
pendant toute sa dur6e. Au prealable, une procedure d'acceptation d'appel 
permet au reseau de savoir s'il peut supporter I'appel. Dans le cas ou aucun canal 
5 n'est disponible, Pappel est rejet§. 

Dans les reseaux a commutation de paquets ou le trafic est, par 
definition, imprevisible, la nature variable des debits offre Popportunite d'un 
partage statistique des ressources du r§seau. Cette optimisation des ressources 
augmente, malheureusement, les risques de congestion. Ces reseaux peuvent 
10 §tre vus comme une succession de files d'attente a capacite limitee dont il 
convient de controler le remplissage afin d'eviter leur saturation, synonyme de 
perte de paquets. 

II est connu de controler le trafic par un mecanisme dit "de 
fenetrage" : lorsqu'un etat de saturation est detecte, le recepteur demande 
15 explicitement a la source de reduire son flux. On parte alors de regulation et de 
controle de flux. 

Aucune de ces approches n'est suffisante, la premiere parce qu'elle 
conduit a un gaspillage inevitable des ressources du reseau en allouant a la 
source une bande passante correspondant a son debit maximal et la seconde 

20 parce que le rapport du temps de propagation sur le temps de transmission 
augmente de maniere considerable lorsque les liaisons sont a tres haut d6bit. 
Dans les systemes de controle de flux par retroaction, entre I'instant d'emission de 
la notification de congestion et I'instant de sa reception par le dispositif de 
communication source, le trafic dej§ en transit dans le reseau peut etre consid6re 

25 comme d6finitivement perdu en raison de la congestion, a moins de disposer de 
m6moires de grande capacite pour conserver tous les paquets en transit pendant 
Petat de congestion. 

Par consequent, pour la commutation rapide de paquets, les 
m^thodes de controle purement r6actives sont insuffisantes dans un 
30 environnement haut debit. La commutation necessite des mecanismes elabor6s 
dans les 6quipements de commutation (noeuds intermediaires du reseau) incluant 
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des methodes preventives et des methodes reactives. La technologie ATM 
("Asynchronous Transfert Mode" ou mode de transfer! asynchrone), propose des 
techniques de gestion de la qualite de service, et de controle de congestion 
bashes sur des mecanismes elabores implementes au sein des 6quipements de 
5 commutation. Des exemples de tels m6canismes sont decrits dans les brevets US 
5,291,481 et US 5,313,454 qui illustrent aussi la complexity et le cout potentiel 
d'implementation de telles methodes. 

Ces methodes ne sont done pas adaptees a des reseaux 
comprenant un nombre plus restreint d'equipements a interconnecter ou le coQt 
10 des moyens de communication ne doit pas etre trop eleve par rapport au cout des 
equipernents a interconnecter. 

Des tentatives d'utilisation de commutateurs ATM embarques ont 
ete faites, telles que celle decrite dans la these "Architecture distribu6e temps reel 
fondee sur ATM" de Jean-Frangois Guilaud (INPG). Cette these mentionne 

15 ('utilisation de la signalisation ATM classique afin de permettre la gestion des 
connexions, ce qui represente une implementation complexe. Cependant, la mise 
en oeuvre complete des mecanismes de gestion des connexions doit prevoir 
d'eviter la congestion, qui, afin de simplifier Tutilisation du commutateur, reposent 
sur une gestion locale des informations de charge et sur Vutilisation des files 

20 d'attente en sortie pour chaque commutateur. 

Le controle de flux strict, a la source, tel qu'il est decrit dans la 
these, prevoit I'utilisation d'un mode connecte uniquement, et v6rifie le non 
depassement du transfert de donnees par rapport a ce qui a ete pr§vu lors de 
Tetablissement de la connexion correspondante. Cela peut done engendrer une 
25 mauvaise utilisation des res sources reseau ainsi qu'un manque de flexibility du 
systeme. 

Par ailleurs, il n'est envisage aucun moyen simple pour r6agir au 
probl6me de congestion si ce n'est en se reposant sur les solutions d6crites 
pr6cedemment, propre a I'utilisation de TATM, mais qui demeurent des solutions 
30 complexes. 
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De plus, Tutilisation d'une dimension de paquet fixe, conformement 
a I'ATM, engendre une perte fixe du debit utile par lien du reseau disponible. En 
revanche, une taille de paquet variable en fonction de la charge du reseau permet 
d'optimiser le debit utile. Les techniques de controle de la taille des paquets ont 
deja ete testees sur des architectures reseau de type bus ou anneau. 

La commutation asynchrone de paquets, telle que decrite dans la 
norme IEEE-P1355, est basee sur une technologie de commutation (matrice de 
commutation non bioquante permettant plusieurs chemins simultan§s) a faible 
cout de realisation en ce qui concerne le commutateur. En effet, le commutateur 
en question n'utilise qu'un minimum de ressources pour effectuer la commutation 
d'un paquet a partir d'un port d'entree vers un port de sortie. Le transfert d'un 
paquet au travers du commutateur a lieu des que le commutateur a connaissance 
des informations de commutation du dit paquet (en-tete de paquet) sans attendre 
la complete reception de toutes les donnees du paquet. II n'y a done aucune 
gestion de file d'attente ou de priorite dans les noeuds intermediaires du chemin. 

Par ailleurs, afin de regler les problemes de contention d'acces a un 
port d'entree (respectivement vers un port de sortie) du commutateur, lorsque 
plusieurs paquets sont a priori destines a transiter via ce port d'entree 
(respectivement de sortie), un mecanisme de controle de flux au niveau du lien 
est implements, n'autorisant une source a transmettre des donnees sur la ligne de 
transmission que lorsqu'elle a obtenu I'autorisation de la part de la destination, 
c'est-&-dire lorsqu'un groupe de donnees pr6cedemment emises par la source ont 
ete acquittees par la destination. 

Cependant, la commutation asynchrone de paquets, telle que 
connue dans Tetat de la technique, si elle laisse envisager des coQts 
d'impl6mentation attractifs, ne prevoit pas de garantir differentes qualit6s de 
service pour les trafics concurrents au sein d'un meme reseau. 

Les technologies de type bus s6rie proposent une alternative a 
Tutilisation de la commutation de paquets pour interconnecter des periph6riques a 
moindre cout. En effet, les m§canismes mis en oeuvre pour partager les 
ressources se trouvent simplifi6s du fait de I'unicit6 de la ressource principale, en 
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roccurrence le medium de communication. Cette simplicity implique aussi 
I'inconvenient d'une bande passante limitee : la bande passante moyenne 
disponible par terminal diminue en fonction du nombre de terminaux connectes. 

Certaines technologie bus serie, telles que celle normalis6e par 
I'lEEE, reference P1394, d6finie pour Interconnexion d'6quipements multimedia, 
supportent le transfert des donnees selon principalement deux classes de service 
en mettant en oeuvre une architecture logique de type bus. Des mecanismes sont 
done necessaires pour arbitrer I'acces au bus et organiser le transfert des 
donnees. Cette technologie de bus serie prevoit un mecanisme de reservation de 
ressources. II permet, d'une part, la transmission de donnees dite isochrone, 
comprenant une phase de reservation, et f d'autre part, la transmission de 
donnees dite asynchrone, sans phase de reservation. 

Le document US-A-5,042,027 decrit une methode de 
communication organisee autour d'un systeme centralise pour collecter des 
informations de charge sur le reseau afin d'optimiser la selection des chernins. 

Le document US-A-5,347,51 1 decrit une organisation detaill6e des 
informations de charge sur les liens en fonction des classes de services, ces 
informations etant stockees dans une base de donnees. 

Dans les deux cas, le bon fonctionnement de ces methodes 
repose sur la validite des informations de charge et done sur la rapidite de mise 
a jour de ces informations. Cette mise a jour constitue un objet de la presente 
invention. 

Uinvention vise a permettre, sur un reseau a commutation de 
paquets, d'une part, la synchronisation de la mise a jour de tables de charge pour 
chaque noeud et de I'etablissement de cette connexion, et, d'autre part, de limiter 
les echanges de messages de controle utilises pour cette synchronisation. 

Dans son application & un reseau commute, la presente invention 

vise aussi : 

- a garantir un acces equitable aux ressources du r6seau 
comprenant plusieurs equipements multimedias ; 



- a organiser le transfert de paquets afin que certains de ces 
paquets traversent le reseau avec un temps de latence inferieur a une valeur 
maximale garantie ; 

- a garantir, pour un groupe de paquets formant un flux, une valeur 
de bande passante determinee ; 

- a privilegier remission de certains paquets dont le contenu d6crit 
des messages dits "de controle", 

- a optimiser 1'utilisation de la bande passante effective du reseau, 

- a detecter et a circonvenir les congestions du reseau, et 

- a affranchir les commutateurs des noeuds intermediates de tout 
traitement concemant I'organisation du sequencement des paquets. 

A cet effet, la presente invention vise un proced6 de 
communication sur un r6seau, entre des dispositifs de communication 
susceptibles, chacun, de determiner le chemin a faire suivre £ chaque 
information qu'il a a transmettre, caracterise en ce qu'il comporte : 

- effectu6e par chaque dispositif de communication dit "source", 
qui a besoin d'une connexion associee & un chemin, pour effectuer une 
transmission d'information & destination d'un dispositif de communication 
destinataire, une operation de demande de connexion, au cours de laquelle, le 
dispositif de communication source transmet, a destination de chaque dispositif 
de communication dudit chemin, une demande d'6tablissement de connexion, 

- lorsque I'etablissement de ladite connexion est possible, 
effectuee par au moins le dispositif de communication destinataire, une 
operation de transmission a destination du dispositif de communication source 
d'une acceptation de connexion, 

- effectuee par le dispositif de communication source, une 
operation de diffusion, £ tous les dispositifs de communication du r6seau, d'une 
information representative de Petablissement de la connexion, 

- effectu6e par chaque dispositif de communication dudit chemin, 
a reception de ladite information representative d'etablissement de connexion, 
une operation de confirmation d'6tablissement de ladite connexion, et 
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- effective par chaque dispositif de communication en dehors 
dudit chemin, a reception de ladite information representative d'etablissement 
de connexion, une operation de mise en m6moire d'une information 
representative de ladite connexion. 
5 Grace a ces dispositions, la meme information, diffusee a tous les 

dispositifs de communication du reseau sert, d'une part, a confirmer 
Tetablissement de la connexion aupres de tous les dispositifs de communication 
du reseau qui se trouvent sur le chemin associe a la connexion et, d'autre part, 
a informer tous les dispositifs de communication qui ne sont pas sur ledit 
10 chemin, de l'£tablissement de la connexion. 

Ainsi, chaque dispositif de communication du reseau est inform^ 
de chaque etablissement de connexion et peut done determiner I'opportunite 
d'une transmission ou d'une diffusion sur ledit reseau. Des congestions du 
reseau peuvent done etre ainsi evites. 
15 La coherence de Information du r£seau est ainsi renforcee. 

Selon des caracteristiques particulieres, chaque dispositif de 
communication dudit chemin effectue, a reception de la demande 
d'etablissement de connexion, une operation de verification de la possibility 
d'etablissement de ladite connexion. 
20 Grace a ces dispositions, les dispositifs de communication 

intermediates evitent les congestions du reseau. 

Selon d'autres caracteristiques particulieres, chaque dispositif de 
communication dudit chemin, lorsque, au cours de Pop6ration de verification, la 
possibility d'etablissement de la connexion a ete verifiee, effectue une operation 
25 de reservation de ressources necessaires a ladite connexion. 

Grace d ces dispositions, ces ressources sont r£serv6es jusqu'S 
ce que, a reception de reformation diffus6e par le dispositif de communication 
source, la connexion soit prise en compte. 

Ainsi, des risques de confiit d'etablissement de connexion sont 
30 6vit6s meme si Tetablissement d'une connexion n'a pas encore ete confirme. 

Selon d'autres caracteristiques particulieres, chaque dispositif de 
communication dudit chemin, lorsque, au cours de I'operation de verification, la 



possibility d'etablissement de la connexion n'est pas v6rifiee, effectue une 
operation de transmission, a destination du dispositif de communication source 
d'une information representative de Pimpossibilite de la mise en place de la 
connexion par ledit dispositif de communication intermediate. 

Grace a ces dispositions, des que I'etablissement de la connexion 
envisagee s'avere impossible sur le chemin envisage, le dispositif de 
communication source en est informe. 

Selon d'autres caracteristiques particulieres, lorsque 
I'etablissement de ladite connexion est possible, I'operation de transmission, a 
destination du dispositif de communication source, d'une information 
representative d'une acceptation de connexion, est effectuee uniquement par le 
dispositif de communication destinataire. 

Grace a ces dispositions, reformation representative 
d'acceptation de connexion peut etre emis par le dispositif de communication 
destinataire selon tout mode de transmission, et sur tout chemin du reseau. 

Ceci ameliore Tefficacite de Tetablissement de la connexion et 
supprime le traitement d'une information d'acceptation de connexion dans 
chacun des dispositifs de communication intermediates. 

Selon d'autres caracteristiques particulieres, pour transmettre 
ladite information representative d'une acceptation de connexion, le dispositif 
de communication destinataire effectue une operation de choix de chemin 
independant du chemin associe a la connexion en cours d'etablissement. 

Ainsi, le chemin le moins charge peut etre choisi et refficacite de 
retablissement de la connexion peut etre amelioree. 

Selon d'autres caracteristiques particulieres, le procede tel que 
succinctement expose ci-dessus comporte, au cours de I'etablissement d'une 
connexion, effectuee par chaque dispositif de communication du reseau, une 
operation de mise & jour d'une table de charge contenant des informations 
representatives de charges de liens du r6seau incorpores dans un chemin 
associe a une connexion. 

Grace £ ces dispositions, chaque dispositif de communication 
possede une table de charge qui lui permet de determiner la disponibilite de 
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chaque lien ou de chaque chemin clu reseau, soit pour les transmissions 
d'information qu'il pourrait avoir a effectuer soit a titre de dispositif de 
communication intermediate ou de dispositif de communication destinataire. 

Ainsi, la quantite d'information a traiter est limitee a celle qui 
5 correspond aux connexions valides. 

Selon d'autres caracteristiques particulieres, ('operation de 
diffusion, & tous les dispositifs de communication du reseau, d'une information 
representative de I'etablissement de la connexion, operation effectuee par le 
dispositif de communication source, est effectuee sur un arbre de recouvrement 

10 du reseau dont au moins la moitie des feuilles sont des dispositifs de 
communication intermediates ou le dispositif de communication destinataire, sur 
le chemin associe a la connexion. 

Ainsi, on fait en sorte que Toperation d'information precede aussi 
souvent que possible ('operation de confirmation qui, dans ce cas, n'aura pas 

15 lieu si un dysfonctionnement du reseau intervient dans un dispositif de 
communication qui n'est pas sur le chemin associe a la connexion en cours 
d'etablissement. Ainsi, certains problemes de fonctionnement du reseau 
peuvent etre detectes. 

Selon des caracteristiques particulieres, la demande 

20 d'etablissement de connexion emise par le dispositif de communication source 
comporte une information representative du service requis pour la transmission 
en mode connects associ6e & ladite connexion. 

Grace a ces dispositions, chaque dispositif de communication peut 
determiner les parametres de transmission qui dependent du service requis. 

25 Selon un deuxieme aspect, la presente invention vise un dispositif 

de communication sur un reseau comportant des dispositifs de communication 
susceptibles, chacun, de determiner le chemin £ faire suivre d chaque 
information qu'il a £ transmettre, caracterise en ce qu'il est adapte, lorsqu'il a 
besoin d'une connexion associ6e a un chemin, pour effectuer une transmission 

30 d'information & destination d'un dispositif de communication destinataire : 
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- a faire transmettre a un moyen de transmission, a destination de 
chaque dispositif de communication dudit chemin, une information de demande 
d'6tablissement de connexion, et 

- a r6ception d'une information d'acceptation de connexion en 
5 provenance du dispositif de communication destinataire, a faire diffuser, par 

ledit moyen de transmission, a tous les dispositifs de communication du reseau, 
une information d'6tablissement de la connexion. 

L'invention vise aussi un ordinateur, une camera, un tel£copieur, 
un appareil photographique, un televiseur, une imprimante, un scanner et un 
10 lecteur audio/vid6o, caract6ris6s en ce qu'ils comportent un dispositif tel que 
succinctement expose ci-dessus. 

L'invention vise aussi : 

- un moyen de stockage d'informations lisible par un ordinateur ou 
un microprocesseur conservant des instructions d'un programme informatique 

15 caracterise en ce qu'il permet la mise en oeuvre du procede de l'invention telle 
que succinctement exposee ci-dessus, et 

- un moyen de stockage d'informations amovible, partiellement ou 
totalement, et lisible par un ordinateur ou un microprocesseur conservant des 
instructions d'un programme informatique caracterise en ce qu'il permet la mise 

20 en oeuvre du proc§de de l'invention telle que succinctement exposee ci-dessus. 

Les caracteristiques preferentielles ou particulieres, et les 
avantages de ce dispositif, de cet ordinateur, de cette camera, de ce 
telecopieur, de cet appareil photographique, de ce televiseur, de cette 
imprimante, de ce scanner, de ce lecteur audio/video et de ces moyens de 

25 stockage d'informations etant identiques k ceux du proced6 tel que 
succinctement expose ci-dessus, ces avantages ne sont pas rappeles ici. 

D'autres avantages et caracteristiques de invention ressortiront 
de la description qui va suivre, faite en regard des dessins annexes dans 
lesquels : 

30 - la figure 1 represente un reseau de noeuds interconnects, 

- la figure 2 repr6sente un dispositif (ou "moyen") de 
communication selon la pr6sente invention, 
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- la figure 3 represente des echanges de messages intervenant 
entre un noeud source et un noeud destinataire pour vehiculer d'une part un 
trafic connecte et, d'autre part, un trafic non connecte, 

- la figure 4 represente un organigramme mis en oeuvre par le 
5 moyen de communication du noeud dit "source" pour une transmission en 

mode connecte, 

- la figure 5 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "intermediaire" pour une transmission 
en mode connecte, 

10 - la figure 6 represente un organigramme mis en oeuvre par un 

moyen de communication d'un noeud dit "destinataire" pour une transmission 
en mode connecte, 

- la figure 7 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "voisin" pour une transmission en 

15 mode connecte, 

- la figure 8 represente un reseau sur lequel circulent des 
messages de controle destines a la gestion du mode connecte, 

- la figure 9 represente la structure de messages de controle 
destines a la gestion du mode connecte, 

20 - la figure 10 represente la structure de donnees d'une table de 

charge en memoire d'un moyen de communication, 

- la figure 11 represente la structure de donnees d'une table de 
specifications et de priorites contenant des canaux virtuels reserves a la 
transmission en mode connects, en memoire d'un moyen de communication, 

25 - la figure 12 represente un organigramme d'emission en modes 

connects et non connecte d'un moyen de communication tel qu'illustre en figure 2 f 

- la figure 13 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour l'6tablissement d'une connexion, 
incorpore dans Porganigramme de la figure 4, 
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- la figure 14 represente un organigramme de determination, par un 
noeud intermediate ou le noeud destinataire, de disponibilite de chemin pour 
Tetablissement d'une connexion, incorpore dans I'organigramme de la figure 5 ou 
6,et 

5 - la figure 15 represente un organigramme de determination, par un 

noeud voisin, de disponibilite de chemin pour Tetablissement d'une connexion, 
incorpore dans Torganigramme de la figure 7. 

Dans toute la presente demande les termes "dispositifs de 
communication " et "moyen de communication" ont la meme signification et 
10 designent les memes combinaisons de moyens objets de la presente invention. 

Le mode prefere de realisation gere trois classes de service 
specifiques, deterministe (en mode connecte), garantie (en mode connecte) et 
elastique (en mode non connecte), sur un reseau a commutation de paquet. 

En figure 1, on observe cinq equipements multimedias 101 & 105 
15 d'un reseau a commutation de paquet 100, relies entre eux par six liens 106 a 
111. Chaque equipement multimedia comporte un moyen de communication 
112 et un moyen de traitement de donnees 113. Le moyen de communication 
112 permet au moyen de traitement 113 d'ouvrir une connexion d£di£e & un 
trafic connecte (trafic temps reel deterministe ou garanti) puis de g6n6rer ce 
20 trafic, ou bien de generer directement un trafic non connecte (trafic eiastique). 

Lorsque I'equipement multimedia 101 envoie un paquet de 
donnees a I'equipement multimedia 105, par Tintermediaire des liens 108 et 
110, I'equipement 101 est un noeud "source", I'equipement 105 est un noeud 
"destinataire", I'equipement 102, par lequel transitent les donnees, est un noeud 
25 "intermediaire", tandis que les noeuds 103 et 104 sont des noeuds "voisins", 
aucune des donnees transmises ne transitant par I'un d'entre eux. 

Le mode de realisation decrit et repr6sente concerne un n§seau 
local compose de plusieurs noeuds interconnects par des liens bidirectionnels 
rapides. Chaque noeud incorpore un commutateur non bloquant possedant une 
30 matrice de commutation & reception et emission simultan6es (en anglais "cut- 
through crossbar") et possede un certain nombre de ports externes auxquels 
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peuvent etre raccordes des liens. Dans un tel reseau, la route ou le chemin 
suivi par un paquet est une succession de liens, chacun des liens etant defini 
par les deux noeuds qu'il rejoint. 

La communication sur un tel reseau est dite "commutSe". Un 
5 exemple d'un tel r6seau est donn6 par un systeme utilisant des composants 
selon la norme IEEE 1355. 

En figure 2, on observe un schema bloc d'un moyen de 
communication 112 du reseau, comportant un composant commutateur/routeur 
209 couple a une unite centrale 206 (decomposee en deux entit6s 206A et 206 
10 B). 

Le composant commutateur/routeur 209, constitu6 d'un 
composant de la marque SGS-THOMSON (marque deposee), reference ST 
C104, comporte des ports physiques relies a un connecteur 230, et deux ports 
internes dont Tun est dedie au controle, relies a I'unite centrale 206 par 
1 5 I'intermediaire de differents composants decrits ci-dessous. 

On observe ici que le composant commutateur/routeur 
susmentionne 209 ST C104 possede, en fait, trente-deux ports physiques en 
plus de deux ports de controle, seulement un port de controle et quelques ports 
physiques etant representes en figure 2. Des composants d'interface 213 et 
20 216 sont relies aux deux ports internes du composant commutateur/routeur 209 
et sont, chacun, bases sur un composant reference ST C101 et fabrique sous la 
marque SGS-THOMSON. 

Le composant commutateur/routeur 209 et les composants 
d'interface 213 et 216 effectuent un codage conforme a la norme IEEE 1355. Le 
25 composant commutateur/routeur 209 est 3 architecture de type non bloquante. 

Des emetteur/r§cepteurs, non repr§sent§s, plus connus sous leur 
d6nomination technique de langue anglaise u transceiver convertissent des 
signaux TTL, sur les ports physiques du composant commutateur/routeur 209 
en signaux differentiels sur le connecteur 230. 




Les emetteurs/recepteurs sont, par exemple, des composants de 
la marque AT&T (marque deposee) referenc6s 1 141 MK. 

Le connecteur 230 est destin6 a etre relie & plusieurs connecteurs 
identiques incorpores a d'autres moyens de communication du reseau. lis sont 
5 de la marque deposee HARTING et de r6f6rence 2721-121-8000. 

Les composants d'interface 213 et 216 sont relies, par une liaison 
parallele, a une interface PCI 208, elle-meme reliee a un bus PCI 231. 
L'interface 208 est, par exemple, composee d'un circuit AMCC (marque 
deposee) S5933. Le bus PCI 231 est, en outre, relie : 

10 - a un composant d'interface 232, identique au composant 208, lui- 

meme relie au moyen de traitement 113 (figure 1 ) ; 

- a une interface de controle 203, par exemple constitute d'un 
composant 82439 HX de marque INTEL ©, lui meme relie a un bus local d'unite 
centrale 206, comportant un microprocesseur 206A et une memoire cache 

15 statique 206B, et a une m6moire dynamique 204 (constitute des deux entites 
204A et 204 B) ; et 

- a un composant d'interface 205, par exemple de r6f6rence 
82371 5B de marque INTEL ©, ce composant ttant relie a un bus ISA qui relie 
un controleur ISA de peripheriques 233, a une memoire flash de systeme 

20 d'exploitation BIOS 234, a une horioge temps-reel 235 et a une extension de 
memoire flash 236. 

L'architecture et les composants du moyen de communication 112 
sont bien connus de I'homme du metier des systemes informatiques et ils ne 
sont pas plus detailles ici. 

25 Pour une meilleure comprehension de la constitution du mode de 

realisation decrit et representt, le lecteur est invite a consulter les notes 
d'utilisation des composants, notes foumies par leurs constructeurs respectifs. 

L'unite centrale de traitement CPU 206 est composee d'un 
microcontroleur 206A de la marque depos6e INTEL et de reference PENTIUM 
30 (marque d6pos6e) avec 32 Mo de m6moire vive dynamique DRAM 204 & titre 
de m6moire de travail, 256 Ko de m6moire statique cache 206B. 




16 



On observe ici que I'expression "segment de memoire" utilisee ci- 
dessous designe, dans chacune des memoires, aussi bien une zone memoire 
de faible capacite (ne conservant que quelques donn6es binaires), qu'une zone 
memoire de grande capacite (permettant de stocker un programme entier). 

5 La m6moire vive 204A conserve des donnees, des variables et 

des resultats intermediates de traitement utilises par les programmes stock6s 
en memoire 204B, dans des segments de memoire portant, dans la suite de la 
description, les memes noms que les donnees dont ils conservent les valeurs. 

En cours de fonctionnement, la memoire flash 204B contient le 
10 BIOS et les logiciels de controle (qui operant avec le systerne d'exploitation 
temps-reel CHORUS (marque d6posee)) qui sont decrits en figure 3 a 7. 

La memoire vive 204 comporte notamment : 

un segment de memoire " userjdata " dans lequel sont 
conservees les informations utilisateur a transmettre, dont, en particulier, le 
15 service requis (cornportant la bande passante necessaire), 

- un segment de memoire " addjdata " dans lequel sont conservees 
des informations additionnelles a transmettre, informations qui definissent, 
notamment, dans son integralite, le chemin a suivre par les donnees utilisateur 
sur le reseau de communication (figure 9), et 

20 - un segment de memoire " Tables " dans lequel sont conservees 

une table de charge de chemins et une table de charge de liens cornportant des 
informations decrivant tous les chemins dont le noeud considere est la source 
et tous les liens faisant partie de ces chemins (figures 10 et 11). 

La zone d'extension de m6moire 236 est adaptee a conserver : 

25 - le programme de fonctionnement de I'unite centrale de traitement 

206, dans un segment de m6moire " programl et 

- un identificateur representatif du moyen de communication 112, 
identificateur qui est unique sur le r6seau de communication. 

A ('initialisation du moyen de communication, le programme stock§ 
30 dans la memoire d'extension 236 est au moins partiellement copie et organist 
dans la zone m6moire d'execution 204B. 
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La zone d'extension de memoire 236 constitue un moyen de 
stockage d'informations lisibles par un ordinateur ou un microprocesseur, 
conservant des instructions d'un programme informatique caracterise en ce qu'il 
permet la mise en oeuvre du proced6 de I'invention. Selon une variante, la zone 
5 d'extension de memoire 236 est amovible, partiellement ou totalement, et 
comporte, par exemple, une bande magnetique, une mdmoire flash, une 
disquette ou un compact disque a memoire figee ("CD-ROM" en anglais). 

Dans le mode de realisation decrit et represents, le moyen de 
traitement utilise le moyen de communication conforme a I'invention. Le moyen 

10 de traitement demande I'etablissement d'une connexion au moyen de 
communication en lui faisant part du service requis ("application requirement" 
en anglais). Ces parametres dits de "service requis" sont, d'une part, transmis 
dans certains messages de signalisation et, d'autre part, utilises pour calculer 
les parametres de transmission ("trafic parameters" en anglais). Le service 

15 requis est I'etalon utilise pour la mise a jour des tables de charges dans les 
differents noeuds du reseau car il ne depend pas de P6tat respectif des tables 
de charges. 

Les organigrammes objets des figures 4 a 7 n'illustrent que 
partiellement le fonctionnement des dispositifs de communication. 

20 L'unite centrale de traitement 206 est adaptee a mettre en oeuvre 

les organigrammes d6crits en figures 4 a 7. 

En figure 3, on observe, symbolises par des fleches descendantes 
placees dans une colonne centrale, des messages transmis sur le reseau, entre 
un noeud source, & gauche, et un noeud destinataire, a droite. Les fleches 
25 orientees de la gauche vers la droite correspondent a des messages transmis 
depuis le noeud source des donn6es utilisateur a destination du noeud 
destinataire de ces donnees et les fleches orientees de la droite vers la gauche 
correspondent a des messages transmis depuis le noeud destinataire des 
donn6es utilisateur vers le noeud source de ces donn6es. 

30 Dans la colonne de gauche, sont represents les messages 

6chang6s entre le moyen de traitement du noeud source (£ gauche) et le 
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moyen de communication du noeud source (a droite de la colonne de gauche). 
Dans la colonne de droite, sont repr6sent§s les messages echanges entre le 
moyen de traitement du noeud destinataire (a droite) et le moyen de 
communication du noeud destinataire (& gauche de la colonne de droite). 

5 Les six fleches 251 a 256 de la colonne centrale correspondent & 

un mode de communication connecte conforme a la presente invention, les 
fleches 257 et 258 correspondent & une transmission en mode non connecte 
avec synchronisation des deux moyens de traitement et la fleche 259 
correspond a une communication en mode non connecte sans synchronisation 
10 des deux moyens de traitement. 

Dans la colonne centrale, les fleches 254, 257, 258 et 259 
correspondent a des transferts de donnees sur le reseau, les autres fleches 
correspondant a des messages organisant ces transferts. 

En mode connecte, c'est-a-dire dans le cas du trafic connecte, le 
15 moyen de traitement du noeud source informe le moyen de communication du 
noeud source de I'ouverture d'une connexion en lui envoyant un message de 
requete de connexion ("connect_req") 

En consequence, le moyen de communication du noeud source 
lance la phase d'initialisation ("set-up" en anglais). Cette phase comporte 
20 notamment remission d'un message d'initialisation 251 (message "set-up") par 
le moyen de communication du noeud source et a destination du moyen de 
communication du noeud destinataire (par Pintermediaire, le cas 6ch6ant f du 
moyen de communication de chaque noeud intermediate). 

A reception du message de "sef-up", le moyen de communication 
25 du noeud destinataire informe le moyen de traitement du noeud destinataire 
qu'il a regu une demande d'ouverture de connexion, par Pintermediaire d'un 
message de demande d'ouverture de connexion "connectJndt\ 

Si la demande est acceptee, le moyen de communication du 
noeud destinataire est inform^ par le moyen de traitement du noeud 
30 destinataire, par Pintermediaire d'un message "connectjans" (identify en figure 
6 par le nom "callRequest^ack" pour acceptation de requete d'appel ou de 
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"callRequestjnacK\ pour rejet de requete d'appel, selon le resultat de la demande 
d'ouverture de connexion, operations 377 et 378 respectivement. Dans le premier 
cas, un message de connexion 252 ("connect*) est emis par le moyen de 
communication du noeud destinataire vers le moyen de communication du 
5 noeud source. 

Le moyen de traitement du noeud source est alors informe du bon 
deroulement de I'ouverture de la connexion par un message de confirmation de 
connexion "connectjcfr", de la part du moyen de communication du noeud 
source. Le moyen de communication de chaque noeud du reseau est alors 
10 informe de I'etablissement d'une nouvelle connexion par rinterrnediaire d'un 
message 253 de mise a jour de table de charge "LinkTabLoad" diffuse par le 
moyen de communication du noeud source. Ce message est aussi utilise pour 
confirmer aupres des noeuds intermediaires et du noeud destinataire le bon 
deroulement de la phase d'etablissement de la connexion. 

15 Le transfert de donn6es composant le trafic connecte associe a la 

connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A 
cet effet, le moyen de traitement du noeud source et le moyen de 
communication du noeud source 6changent des messages de demande 
d'emission d'un message de donnees n sendlsoData_req" et de confirmation 

20 d'emission du message de donnees "sendlsoData__cfi*\ 

Le transfert des messages de donnees 254 est alors effectue 
apres segmentation du flot de donnees en paquets de taille pred6finie. Le 
moyen de communication du noeud destinataire regoit les paquets de donnees 
qu'il confie au moyen de traitement du noeud destinataire, par Tinterm6diaire du 
25 message de reception d'un message de donnees n sendlsoData_incT), apres 
avoir restructure le flot de donnees. 

Lorsque les donnees & transmettre ont 6te transmises, le rhoyen 
de traitement du noeud source peut d6cider de la fermeture d'une connexion en 
transmettant un message de demande de fermeture de connexion 
30 "release_req" au moyen de communication du noeud source. 



Le moyen de communication du noeud source emet alors : 
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- un message de confirmation de relachement "release_cfr" a 
destination du moyen de traitement du noeud source, 

- un message de relachement "release" 255 £ destination des 
eventuels noeuds intermedia ires et du noeud destinataire, et 

5 - un message 256 de mise a jour de table de charge "LinkTabFree" 

a tous les noeuds du reseau. 

Le message 256 est utilis6 pour confirmer aupres des noeuds 
intermediates, des noeuds voisins et du noeud destinataire le bon deroulement 
de la phase de liberation de la connexion. Au niveau du noeud destinataire, le 
10 moyen de communication informe le moyen de traitement de la fermeture de la 
connexion par Pintermediaire d'un message de notification de fermeture de 
connexion " 'release JncF\ 

Le transfert de donnees pour le trafic elastique, en mode non 
connecte avec synchronisation des moyens de traitement, se fait sans 

15 ouverture prealable d'un connexion, par la transmission du message d'emission 
de message "sendSyncData_req n par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 257 des donnees apres segmentation du 
flot de donnees en paquets de taille predefinie. Au niveau du noeud 

20 destinataire, la reception des donnees est effectuee par le moyen de 
communication, qui informe le moyen de traitement, et transmet le flot de 
donnees restructure, par Tusage du message de reception de message 
n sendSyncDataJn<f\ En reponse, le moyen de traitement du noeud destinataire 
emet, a destination du moyen de communication du noeud destinataire, un 

25 message de bonne reception n sendSyncData_ans", qui contient la reponse du 
moyen de traitement du noeud destinataire et provoque le transfert d'un 
message 258 entre le moyen de communication du noeud destinataire et le 
moyen de communication du noeud source. A reception de ce message 258, le 
moyen de communication du noeud source emet a destination du moyen de 

30 traitement du noeud source un message de confirmation de transmission 
n sendSyncData_cfr". 
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Le transfert de donnees pour le trafic 6lastique, en mode non 
connecte sans synchronisation des moyens de traitement, se fait sans 
ouverture prealable d'un connexion, par la transmission du message d'emission 
de message n sendAsyncData_req n par le moyen de traitement du noeud source 
5 vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 259 des donnees apres segmentation du 
flot de donnSes en paquets de taille predefinie et emet a destination du moyen 
de traitement du noeud source un message de confirmation de transmission 
"sendAsyncData_cff '. Au niveau du noeud destinataire, la reception des 
10 donn6es est effectuee par le moyen de communication, qui informe le moyen 
de traitement et transrnet le flot de donn6es restructure, par I'usage du 
message de reception de message "sendAsyncData_ind". 

Les figures 4 a 7 illustrent les procedures de gestion des 
connexions selon I'invention. 

15 En ce qui concerne le moyen de communication du noeud source, 

apres avoir et6 dans un etat d'initialisation 300 (figure 4), un message entrant 
"connect_req" est regu au cours d'une operation 301, de la part du moyen de 
traitement du noeud source. Ce message comporte le service requis, dont la 
bande passante, et le mode de transmission. Le moyen de communication du 

20 noeud source effectue alors la selection d'un chemin alloue a la connexion, le 
calcul des parametres de transmission en fonction du service requis puis la 
mise a jour de la table de charge si un chemin est disponible (figure 13), au 
cours d'une operation 302. 

Ensuite, au cours d'un test 304, le moyen de communication du 
25 noeud source determine si la bande passante necessaire & la connexion 
envisagee est disponible sur le chemin s6lectionne, ou non. Cette procedure de 
test 304 est connue sous le nom de " Controle d'Admission de Connexion " ou 
encore "CAC". Lorsque le resultat du test 304 est negatif, au cours d'une 
operation 303, le moyen de communication emet un message de refus 
30 d'ouverture (message "connect_cfi" n6gatif) de communication § destination du 
moyen de traitement du noeud source. Ce message de refus n connect__cff" 
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n§gatif a pour effet d'avertir I'application logicielle qui avait requis la 
transmission de I'impossibilite d'effectuer cette transmission en mode connecte. 

Ensuite, les ressources associees a la gestion de la connexion 

sont liberees. 

5 Lorsque le resultat du test 304 est positif, au cours d'une operation 

305, le moyen de communication 6rnet le message 251 "set-up" (figure 3) d 
destination du moyen de communication du noeud destinataire, par 
rinterm6diaire de chacun des dispositifs de communication des eventuels 
noeuds intermediates. Ce message 251 d6crit la connexion a etablir (voir figure 
10 9). 

Ensuite, au cours d'une operation 306, un compteur d'horloge (en 
anglais "timer") "cncAckWaif est initialise a une valeur qui correspond a un 
delai maximum accorde a Petablissement de la connexion demand6e. Le 
moyen de communication se met alors dans un etat d'attente de la r6ponse du 
15 reseau quant a Petablissement de la connexion, etat 307. 

Dans cet etat 307, trois evenements differents peuvent se 
produire, au cours d'operations 308, 310 ou 31 1 . 

Lorsque, dans Petat 307, le message entrant est un message 
"cncAckWaif, provenant du passage a zero de la valeur du compteur de 

20 signaux d'horloge n cncAckWaiT initialise au cours de I'operation 306, operation 
308, ou lorsque le message entrant est un message w release_bacK\ provenant 
du noeud destinataire ou de Tun des eventuels noeuds interm6diaires, 
operation 310, Pop6ration 323 est effectu6e, au cours de laquelle le moyen de 
traitement du noeud source est inform^ du rejet de la demande de connexion. A 

25 cet effet, le moyen de communication du noeud source 6met un message 
n openCall_naclf 9 correspondent a un message "connectjcft" n6gatif, notifiant le 
rejet de la connexion, & destination du moyen de traitement du noeud source. 

A la suite de I'operation 323, au cours d'une operation 324, le 
moyen de communication du noeud source procede a la mise a jour des tables 
30 de charge assoctees & la connexion qui a 6te rejet6e. Puis, au cours d'une 
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operation 325, les ressources associees a la gestion de la connexion sont 
Iib6r6es. 

Enfin, lorsque, dans l'6tat 307, le message entrant est un 
message de connexion 252 "connect, provenant du noeud destinataire, 
5 operation 31 1 , le moyen de communication du noeud source effectue remission 
d'un message d'acquittement d'ouverture de connexion "openCalljacK\ 
correspondant d un message n connect__cft" positif, a destination du moyen de 
traitement du noeud source, operation 312, puis, au cours d'une operation 313, 
diffuse un message 253 "LinkTabLoad" comportant notamment la description 

10 du service requis, la bande passante utilisee ainsi que la description du chemin 
correspondant a la connexion, en termes de liens. Ce message est diffuse £ 
destination de tous les noeuds du reseau, ce qui a pour effet que chaque noeud 
du reseau met a jour ses tables de charge. La diffusion de ce message est 
effectu6e en suivant un arbre de recouvrement du reseau, determine selon des 

1 5 techniques connues (voir figure 8). 

Le moyen de communication du noeud source se met alors dans 
Petat 314 au cours duquel il attend une evolution de la connexion et transmet 
toutes les donn6es destinees a etre transmises en mode connects, sur la 
connexion mise en place. 

20 Deux messages peuvent alors entrer dans le moyen de 

communication, au cours d'operations 315 et 318. 

Lorsque, dans I'etat 314, le message entrant est un message de 
relachement provenant d'un autre noeud du reseau "re/ease^bac/c", operation 
315, le moyen de communication du noeud source emet un message de 
25 terminaison de communication "callTerminate", "releasejnd" figure 3, a 
destination du moyen de traitement du noeud source, operation 316, ce qui a 
pour effet d'informer le moyen de traitement de la fermeture de la connexion. 

Puis, le moyen de communication 6met un message d'alarme 
" alarm jdcnBacK\ op6ration 317, a destination du moyen de traitement du 
30 noeud source, ce qui a pour effet de d§clencher le traitement d'une alarme par 
ce moyen de traitement puisque la connexion a 6t6 interrompue de mani&re 
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anormale. Puis, le moyen de communication diffuse a destination de tous les 
autres noeuds du r6seau, un message de mise a jour de tables de charges 
"LinkTabFree", comportant notamment une description du service requis et du 
chemin correspondant a la connexion, en termes de liens, operation 320. 

5 Le moyen de communication effectue alors une operation 321, 

identique d ['operation 324, puis une operation 322 au cours de laquelle les 
res sources associees a la gestion de la connexion sont detruites. 

Lorsque le message regu, dans l'6tat 314, est un message de 
demande de fin de connexion (message "release__req" provenant du moyen de 
10 traitement du noeud source et message "release_cft" t en r6ponse), operation 
318, le moyen de communication emet un message de relachement 255 
"release", operation 319, puis effectue les operations 320, 321 et 322. 

En ce qui concerne chaque noeud intermediate (figure 5), apres 
avoir ete dans un 6tat d'initialisation 300, un message entrant 251 "set-up" est 

15 regu au cours d'une operation 331, de la part du noeud source (voir operation 
305). Le service requis pour la connexion consider6e est alors extrait de ce 
message 251 "set-up". Le moyen de communication du noeud intermediaire 
effectue alors un calcul des parametres de transmission, a partir du service 
requis, puis, si la charge est acceptable, une mise a jour de ses tables de 

20 charge, au cours d'une operation 332, detaillee figure 14. 

Ensuite, au cours d'un test 335, le moyen de communication du 
noeud intermediaire determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non (voir test 304). 

Lorsque le resultat du test 335 est negatif, au cours d'une 
25 op6ration 333, le moyen de communication du noeud intermediaire 6met un 
message de rel§chement de connexion "release_bactC k destination du noeud 
source (voir operation 310). Puis le moyen de communication du noeud 
intermediaire libere les ressources associees & la gestion de la connexion 
consideree, operation 334. 

30 Lorsque le resultat du test 335 est positif, au cours d'une operation 

336, le moyen de communication emet un message d'initialisation "set-up" 251 
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a destination du moyen de communication du noeud destinataire et de chacun 
des moyens de communication des eventuels noeuds intermediates. Ce 
message est emis apres mise a jour du champ identifiant la position du noeud 
dans le chemin, a partir de la description du chemin en termes de liens (voir 
5 figure 9). 

Ensuite, au cours d'une operation 337, le compteur d'horloge 
"cncAckWaif est initialise a une valeur qui correspond a la duree maximale 
accordee a I'etablissement de la connexion. Le moyen de communication se 
met alors dans P6tat 338 d'attente de la r6ponse du reseau quant a 
1 0 I'etablissement de la connexion . 

Dans cet 6tat 338, cinq evenements diff6rents peuvent se 
produire, au cours d'op6rations 339, 341, 345, 346 et 347. 

Lorsque le message entrant est un message n cncAckWaif\ 
provenant du passage a zero de la valeur du compteur de signaux d'horloge 

15 "cncAckWait 1 initialise au cours de Poperation 337, operation 339, le moyen de 
communication emet un message de relachement "re/ease", operation 340, a 
destination du noeud destinataire et des eventuels noeuds intermediates qui le 
separent du noeud destinataire, et 6met un message de relachement 
"release_bacK\ a destination du noeud source et des eventuels noeuds 

20 intermediates qui le separent du noeud source, operation 342. Ensuite, au 
cours d'une operation 343, le moyen de communication du noeud intermediate 
considere procede a la mise £ jour des tables de charge associees a la 
connexion qui a ete rejetee. Puis, au cours d'une operation 344, les ressources 
associees a la gestion de la connexion sont lib£rees. 

25 Lorsque le message entrant est un message "re/ease" 255, 

provenant du noeud source ou d'un noeud intermediaire entre le noeud source 
et le noeud intermediaire consider^, operation 341 , le moyen de communication 
effectue les operations 342 d 344. 

Lorsque, dans I'etat 338, le message entrant est un message 256 
30 "LinkTabFree", operation 347, ce message est memorise et le moyen de 
communication reste dans Petat 338. 
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Lorsque, dans I'etat 338, le message entrant est un message de 
demande de fin de connexion emis par un moyen de controle de noeud, dont la 
fonction est de prendre en compte les differents problemes du rdseau, 
operation 346, ce message est memorise et le moyen de communication reste 
5 dans I'etat 338. 

Enfin, lorsque le message entrant est un message 253 
"LinkTabLoad", comportant notamment la description du service requis, ainsi 
que la description du chemin en termes de liens, en provenance du noeud 
source (voir operation 313), operation 345, le moyen de communication se met 
10 dans un §tat 348 au cours duquel il attend une Evolution de la connexion et 
transmet toutes les donnees destinees a etre transmises en mode connecte, 
sur la connexion mise en place. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud intermediate (et du noeud destinataire), pour fonction de confirmer 
1 5 Petablissement de la connexion, au cours de Toperation 345. 

Dans I'etat 348, trois evenements peuvent se produire, au cours 
d'operations 349, 350 et 351. 

Lorsque, dans I'etat 348, le message entrant est un message 256 
"LinkTabFree", operation 351, ce message est memorise et le moyen de 
20 communication reste dans I'etat 348. 

Lorsque, dans I'etat 348, le message entrant est un message 255 
"release", I'operation 353 decrite plus loin est effectuee. 

Enfin, lorsque, dans I'etat 348, le message entrant est un 
message de demande de fin de connexion, emis par un moyen de controle de 
25 noeud, operation 350, le moyen de communication 6met un message de 
rel§chement " release JbacIC d destination du noeud source, operation 352. 

A la suite de I'une des op6rations 349 ou 352, le moyen de 
communication effectue, au cours d'une operation 353, remission d'un message 
de relachement "release" a destination du noeud destinataire et de chaque 
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eventuel noeud intermediaire qui separe le noeud intermediate considere et le 
noeud destinataire. 

Le moyen de communication effectue alors une operation 354 
identique a Top6ration 324, puis une operation 355 au cours de laquelle le 
5 compteur d'horloge "cncAckWaiT est initialise a une valeur qui correspond d la 
duree maximale accord6e a la liberation de la connexion. Le moyen de 
communication se met alors dans P6tat 356 d'attente de la reponse du reseau 
quant au relachement de la connexion. 

Dans Tetat 356, deux messages peuvent survenir, au cours 
1 0 d'operations 357 et 358. 

Lorsque le message entrant est un message 256 "LinkTabFree", 
operation 357, les ressources associees a la gestion de la connexion sont 
liberees, operation 360. 

Lorsque, dans I'etat 356, le message entrant est un message 
15 ,f cnc>4c/cl/l/a/f , provenant du passage & zero de la valeur du compteur de 
signaux d'horloge "cncAckWaiF initialise au cours de Toperation 355, operation 
358, le moyen de communication ernet un message d'alarme " alarm jdcnTO\ 
operation 359, a destination d'un moyen de controle de noeud, ce qui a pour 
effet de declencher le traitement d'une alarme par ce moyen de traitement 
20 puisque la connexion n'a pas ete relach6e de maniere normale. 

A la suite de Tune des operations 357 ou 359, les ressources 
associees a la gestion de la connexion sont Iiber6es, operation 360. 

En ce qui concerne le noeud destinataire, (figure 6), apres avoir 
6te dans un etat d'initialisation 370, un message entrant n setUp_endF est regu 

25 au cours d'une operation 371, de la part du noeud source ou d'un noeud 
intermediaire. Le moyen de communication du noeud destinataire effectue alors 
I'extraction du service requis, operation 371, puis le calcul des parametres de 
transmission a partir du service requis, et, si la charge est acceptable, la mise & 
jour de la table de charge, au cours d'une operation 372 similaire & ('operation 

30 332, d6crite figure 14. 
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Ensuite, au cours d'un test 373, le moyen de communication du 
noeud destinataire determine si la bande passante necessaire a la connexion 
envisag6e est disponible sur le chemin selectionne, ou non (voir tests 304 et 
335). 

5 Lorsque le resultat du test 373 est negatif, au cours d'une 

operation 333, le moyen de communication du noeud destinataire emet, a 
destination du noeud source et de tous les eventuels noeuds intermediates, un 
message de relachement n release_back", au cours d'une operation 380. 
Ensuite, les ressources associees a la gestion de la connexion sont liberies, 
10 operation 382. 

Lorsque le resultat du test 373 est positif, le moyen de 
communication du noeud destinataire emet, a destination du moyen de 
traitement du noeud destinataire un message de demande de connexion 
"connect_ind" t au cours d'une operation 374. 

15 Puis, le moyen de communication se met dans un etat 375 

d'attente de la reponse du moyen de traitement du noeud destinataire. 

Dans I'etat 375, trois evenements peuvent survenir, au cours 
d'operations 376, 377 et 378. Lorsque le message entrant est un message de 
relachement "release", provenant du noeud source ou de Tun des noeuds 
20 intermediaires, il est memorise au cours de I'operation 376. 

Lorsque, dans I'etat 375, le message entrant est une reponse 
defavorable "ca!IReq_nactf\ correspondant a un message n connect_ans" 
negatif (figure 3), provenant du moyen de traitement du noeud destinataire, 
operation 378, au cours d'une operation 379, le moyen de communication du 
25 noeud destinataire procede a la mise a jour des tables de charge associees a la 
connexion qui a ete rejetee. Puis les operations 380 et 382 sont effectu6es. 

Enfin, lorsque, dans l'6tat 375, le message entrant est un 
message favorable "callReq_acK\ correspondant a un message " connect jans" 
positif (figure 3), en provenance du moyen de traitement du noeud destinataire, 
30 operation 377, le moyen de communication emet un message 252 "connecf, 
directement vers le noeud source, par mise en oeuvre du moyen de routage, au 
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cours d'une operation 381. Ensuite, au cours d'une operation 383, le compteur 
d'horloge "cncAckWait* est initialise a une valeur qui correspond & un delai 
maximum accorde a I'etablissement de la connexion demandee. Le moyen de 
communication se met alors dans Tetat d'attente de la r6ponse du reseau quant 
5 a I'etablissement de la connexion, etat 384. 

Dans cet etat 384, cinq tenements peuvent survenir au cours 
d'operations 385, 386, 387, 389 et 390. 

Lorsque le message entrant est un message de relachernent 
"release", provenant du noeud source ou de Tun des noeuds intermediates, il 
10 est memorise au cours de Toperation 385. 

Lorsque, dans I'etat 384, le message entrant est un message de 
mise a jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de Toperation 389. 

Lorsque, dans I'etat 384, le message entrant est un message de 
15 demande de fin de connexion provenant du moyen de traitement ou d'un 
moyen de controle de noeud, il est memorise au cours de Toperation 386. 

Lorsque, dans Tetat 384, le message entrant est un message 
"cncAckWaif, provenant du passage a zero de la valeur du compteur de 
signaux d'horloge "cncAckWait initialise au cours de ('operation 383, operation 
20 390, le moyen de communication emet un message de relachernent de 
connexion "release^back", operation 391, a destination des noeuds 
intermediates et du noeud source. 

Ensuite, au cours d'une operation 392 f le moyen de 
communication du noeud destinataire procede a la mise & jour des tables de 
25 charge associees a la connexion qui a ete rejetee. Puis, au cours d'une 
operation 393, les ressources associees a la gestion de la connexion sont 
liberees. 

Enfin, lorsque, dans Tetat 384, le message entrant est un 
message 253 "LinkTabLoacT, message comportant notamment la description 
30 du service requis ainsi que la description du chemin en terme de liens 
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(message ayant pour fonction de confirmer Petablissement de la connexion), 
operation 387, le moyen de communication du noeud destinataire se met dans 
un etat 388 d'attente devolution de la connexion. 

On observe ici que le message 253 "LinkTabLoad" a f vis a vis 
5 d'un noeud interm6diaire, pour fonction de confirmer Petablissement de la 
connexion. 

Dans P6tat 388, trois evenements peuvent survenir, au cours 
d'operations 394, 396 et 397. 

Lorsque, dans Petat 388, le message entrant est un message de 
10 mise & jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de Poperation 396. 

Lorsque, dans Petat 388, le message entrant est un message de 
relachement 255 "release", operation 397, le moyen de communication effectue 
la notification "callTerminate", correspondant a un message "release_ind" 
15 (figure 3), de la rupture de la connexion au moyen de traitement du noeud 
destinataire, operation 398. Ensuite, Poperation 399 decrite plus loin est 
effectuee. 

Enfin, lorsque, dans Petat 388, le message entrant est un 
message de demande de fin de connexion emis par un moyen de controle de 
20 noeud, operation 394, le moyen de communication emet un message de 
relachement " release JbacK* a destination du noeud source et des noeuds 
intermediates, operation 395. 

A la suite de Pune des operations 395 ou 398, le moyen de 
communication effectue une operation 399 identique a Poperation 324, puis une 
25 operation 400 au cours de laquelle le compteur d'horloge "cncAckWaif* esV 
initialise a une valeur qui correspond a la dun§e maximale accord£e a la 
liberation de la connexion. Le moyen de communication se met alors dans Petat 
401 d'attente de la reponse du r6seau quant au relachement de la connexion 
de la meme fagon que pour les noeuds intermediaires. 
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Dans I'etat 401, deux messages peuvent survenir, au cours 
d'operations 402 et 403. 

Lorsque le message entrant est un message 256 "LinkTabFree", 
operation 402, les ressources associees a la gestion de la connexion sont 
5 Iib6rees, operation 405. 

Lorsque, dans I'etat 401, le message entrant est un message 
n cncAckWaif\ provenant du passage a zero de la valeur du compteur de 
signaux d'horloge "cncAckWaiT initialise au cours de I'operation 400, operation 
403, le moyen de communication emet un message d'aiarme n alarm_dcnTO n , 
10 operation 404, a destination du moyen de controle de noeud, ce qui a pour effet 
de declencher le traitement d'une alarme par ce moyen de traitement puisque la 
connexion n'a pas ete relachee de maniere normale. 

A la suite de Tune des operations 402 ou 404, les ressources 
associees & la gestion de la connexion sont liberees, operation 405. 

15 En ce qui concerne chaque noeud voisin (figure 7), apres avoir et6 

dans un etat d'initialisation 411, le moyen de communication du noeud voisin 
re?oit un message 253 "LinkTabLoacF, comprenant notamment la description 
du service requis ainsi que la description du chemin en termes de liens, 
operation 412. Ensuite, au cours d'une operation 413, le moyen de 

20 communication du noeud voisin effectue le calcul des param6tres de 
transmission a partir du service requis, puis, independamment de la charge, la 
mise a jour de la table de charge. 

Ensuite, dans I'etat 414, le moyen de communication du noeud 
voisin attend revolution de la connexion. Ensuite, au cours d'une operation 415, 
25 il rego'A un message 256 "LinkTabFree" concernant la connexion, message 
comprenant notamment la description du service requis ainsi que la description 
du chemin en termes de liens. 

Ensuite, au cours d'une operation 416, le moyen de 
communication du noeud voisin proc^de a la mise a jour des tables de charge 
30 associees a la connexion qui a et6 liberee. Puis, au cours d'une operation 417, 
les ressources assoctees a la gestion de la connexion sont Iib6r6es. 
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On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud voisin, pour fonction d'informer sur Petablissement de la connexion. 

Ainsi la procedure (figure 7) correspond plutot a une notification 
qu'a un controle d'admission. 

5 En figure 8 sont representes, dans un reseau a commutation de 

paquets 800 : 

- un noeud source 801 , 

- un noeud destinataire 802, 

- deux noeuds intermediates 803 et 804, 
1 0 - cinq noeuds voisins 805 a 809, et 

- les liens entre ces noeuds. 

Le long de ces liens sont representes des messages transitant 
successivement sur le reseau ainsi constitue, sous forme de fleches. 

On observe que le message 251 "set-up" circule : 
15 - du noeud source 801 au noeud intermediaire 803, puis 

- du noeud intermediaire 803 au noeud intermediaire 804, puis 

- du noeud intermediaire 804 au noeud destinataire 802. 

En revanche, le message 252 "connect' retourne directement du 
noeud destinataire 802 au noeud source 801, sans intervention des noeuds 
20 intermediaires 803 ou 804. Ce message 252 peut, en fait, passer par n'importe 
quel chemin entre le noeud destinataire et le noeud source, par exemple par un 
chemin passant par le noeud voisin 808. 

Enfin, les messages de mise a jour de table de charge 253 
"LinkTabLoad" et 256 "LinkTabFree" sont diffuses a tous les noeuds du reseau, 
25 en suivant un arbre de recouvrement. 

Pr6f6rentiellement, toutes les extr6rnites, ou "feuilles" de I'arbre de 
recouvrement se trouvent sur le chemin de la connexion. Ainsi, lorsqu'H y a une 
panne dans le r6seau, les noeuds du chemin, noeuds intermediaires ou noeud 
destinataire, qui, cornme on Pa vu dans les organigrammes des figures 5 et 6, 
30 attendent le message "LinkTabLoad 19 253, respectivement dans les etats 345 et 
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387, peuvent detecter la panne lorsque Tun des noeuds voisins ne transmet pas 
ce message. 

En figure 9, on observe, sur quatre lignes successives, les 
structures des messages 251 "set-up", 255 "release", de mise a jour de table de 
5 charge, 253 "LinkTabLoacT ou 256 "UnkTabFree" et 252 "connect 1 . 

Le message 251 "set-up" comporte successivement les champs : 

- 901, d'identification du type de message ("set-up", 
"UnkTabLoad", "UnkTabFree", "Connect ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

10 - 903, de description de trafic, repr6sentatif du service requis, 

- 904, de donn6es propres au moyen de communication 
permettant notamment d'identifier les moyens de traiternent des noeuds source 
et destinataire, 

- 905, de nombre de liens qui utilisent le chemin associe & la 

15 connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

20 - 908, de donnees de protocole. 

Le message 255 "release" comporte successivement les 

champs : 

- 901, d'identification du type de message ("set-up", 
"LinkTabLoad", "UnkTabFree", "Connect' ou "Release", voir figure 3), 

25 - 902, d'identification de connexion, 

- 909, de cause de la demande de relachement, 

- 905, de nombre de liens qui utilisent le chemin associ6 d la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le 
30 chemin associe a la connexion, 
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- 907, des descripteurs de liens successifs du chernin 
correspondant a la connexion souhaitee, et 

- 908, de donn6es de protocole. 

Un message de mise a jour de table de charge 253 ou 256 
5 comporte successivement les champs : 

- 901, d'identification du type de message ("set-up", 
"LinkTabLoad", "UnkTabFree", "Connect ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 903, de description de trafic, repr§sentatif du service requis, 

10 - 910, d'information relative a I'arbre de recouvrernent mis en 

oeuvre, 

- 905, de nombre de liens qui utilisent le chemin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
1 5 associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

Le message 252 "connect 1 comporte successivement les 

20 champs : 

- 901, d'identification du type de message ("set-up" ', 
"LinkTabLoad", "UnkTabFree", "Connect ou "Release" , voir figure 3), 

- 902, d'identification de connexion, 

- 911, de donnees de protocole, pouvant etre utilisees par le 
25 moyen de traitement du noeud source. 

- 908, de donnees de protocole. 

En figure 10, on observe des descripteurs de liens 1001 S 1007 
disposes cote & cote et des descripteurs de chemins 1011 a 1015 disposes sur 
des lignes successives. 

30 Chaque descripteur de chemin est une structure de donnees pour 

la description d'un chemin qui comporte, en particulier la reference des liens 
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impliques dans la description de ce chemin et la reference de chaque 
connexion associee a ce chemin. Chaque descripteur de chemin sortant (1011, 
1012 ou 1013) concerne un chemin cree par le moyen de routage du moyen de 
communication. 

Les chemins qui ne partent pas du noeud consid6r6 sont dits 
"temporaires" et permettent de connaTtre les charges des liens des chemins 
sortants. Les chemins temporaires sont cr66s par le moyen de controle de 
charge qui g§re tous les chemins (op6rations 1307, 1407 et 1504, figures 13 d 
15). 

Dans le mode de realisation d6crit et repr6sent6, les chemins 
1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 
1014 et 1015 sont des chemins temporaires (en traits fins). Les chemins 1011, 
1012 et 1013 decrivent la table de routage et sont utilises par le noeud 
considSre pour 6tablir des chemins vers n'importe quel noeud destinataire. 

Chaque descripteur de lien 1001 a 1007 comporte, en particulier, 
la r§f§rence de chaque chemin qui traverse le lien consid6r6, identifie par un 
rectangle, a Pintersection d'une ligne verticale partant du descripteur de lien 
considere et d'une ligne horizontale partant du descripteur de chemin 
considere. 

Les liens 1001 a 1004 font partie d'au moins Tun des chemins 
sortants, et sont representes en traits gras. Chaque intersection de deux lignes 
marquee par un point represente une reference en m6moire : 

- les lignes externes (en haut et/ou a gauche des rectangles) 
reperent les ref6rences conserves avec chaque lien : ces ref6rences 
concement chaque chemin qui traverse ledit lien, et 

- les lignes internes (en bas et/ou a droite des rectangles) rep6rent 
les ref6rences conservees avec chaque chemin : ces ref6rences concement 
chaque lien traverse par ledit chemin. 

La mise a jour de la table de charge effectuee par le moyen de 
controle de charge, comporte les Stapes suivantes : 

- pour r6tablissement d'une connexion : 
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• mise a jour de la charge de tous les liens references par 
le chemin (ajout de charge), et 

• pour chaque lien, mise a jour de la charge de chaque 
chemin r6f6rence pour ce lien ; 

5 - pour le retrait d'une connexion : 

• mise a jour de la charge de tous les liens references par 
le chemin (deduction de charge), et 

• pour chaque lien, mise a jour de la charge de chaque 
chemin reference pour ce lien ; 

10 - pour Pajout d'un chemin : 

• soit par le moyen de routage, lors de Petablissement de 
la table de routage du noeud considere (il s'agit alors 
d'un chemin sortant), ou lors de la mise a jour de la table 
de routage, 

15 • soit par le moyen de controle de charge, lorsque le 

chemin associe a une nouvelle connexion lors de Pajout 
de charge n'est pas deja specifie (il s'agit alors de 
chemin temporaire) ; 

- pour la suppression d'un chemin : 

20 • par retrait d'un chemin temporaire lorsqu'il n'est plus 

traverse par aucune connexion, apres retrait d'une 
connexion, soit lorsque la liste de connexions referencee 
par ce chemin est vide, 

- pour la transformation d'un chemin sortant en chemin temporaire 
25 lorsqu'il ne fait plus partie de la table de routage (a la suite d'une operation de 

mise d jour de la table de routage) ; et 

- pour la suppression d'un lien : 

• par retrait d'un lien lorsqu'il n'est plus traverse par aucun 
chemin, ou lorsque la liste des chemins r6f6renc6s par 

30 led it lien est vide. 

Dans la table de charge, a chaque lien est associ6e une 
information de charge et £ chaque chemin est associ6e une information 
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representative du lien le moins disponible. Ainsi, la bande passante disponible 
du lien le moins disponible est aussi la bande passante disponible du chemin. 

On observe que c'est en utilisant cette information de disponibilite 
de bande passante de chemin, que le moyen de communication effectue le 
5 choix du chemin en choisissant le chemin le plus disponible. Pour chaque 
information a transmettre en mode non connecte, la disponibilite de chaque 
chemin du reseau est ainsi estimee, en fonction du trafic en mode connecte. 

La charge d'un chemin est d£finie a partir de son lien le moins 
disponible. II est caracterise par la bande passante totale qu'il autorise et la part 
10 maximale de la bande passante associee au trafic en mode connects. Etant 
donn6e la charge effective du trafic en mode connecte, chaque moyen de 
communication definit la part associee au trafic en mode non connecte, comme 
egale a la bande passante totale a laquelle on a soustrait la part associee au 
mode connecte. 

15 Le moyen de communication alloue a I'ensemble des 

transmissions en mode non connecte qu'il a a effectuer, tout ou partie de la 
bande passante (preferentiellement une partie, pour eviter des problemes de 
congestion du reseau). Cette part est equitablement repartie entre toutes les 
transmissions en mode non connecte et se trouve done dynamiquement mise ci 

20 jour au debut et a la fin de chaque transmission en mode connecte (lorsque la 
charge du trafic en mode connecte varie). 

L'attribution d'une part est effectuee en definissant un plage de 
valeurs du nombre de paquets a emettre entre deux valeurs extremes 
(spec_CPmin 1114 et specjCPmax 1115 (figure 11). Cette operation 
25 d'attribution de bande passante est effectuee avant remission de Pinformation 
257 ou 259 (figure 3). 

En outre, on considere qu'un chemin qui supporte plus d'un 
nombre predetermine de transmission sortante en mode non connecte n'est 
pas disponible pour une transmission en mode non connecte supptementaire. 

30 Les £v6nements qui peuvent influencer Tattribution de bande 

passante £ une transmission en mode connecte sont de deux types : 
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- ceux qui concernent le mode connecte, I'etablissement ou la 
fermeture d'une connexion, et qui influent sur la bande passante qui lui est 
reserv6e, et, par consequent, sur le nombre de paquets a emettre en mode non 
connects mais aussi sur la taille de ces paquets, et 
5 - ceux qui concernent le mode non connecte, le d6but ou la fin 

d'une transmission, et qui influent sur le nombre de paquets a emettre en mode 
non connecte. 

Pour la gestion de la table de charge illustr6e en figure 10, la 
charge d'un chemin est d£terminee par la charge du lien le moins disponible, en 
10 prenant en compte, pour la charge d'un lien, la somme des charges des 
chemins qui le traversent. 

Les chemins sortants utilises sont etablis par un moyen de 
routage de type connu. 

On observe ici que chaque noeud du reseau controle le flux qu'il 
15 genere et que reformation permettant de controler ces flux est etablie a partir 
de la table de charge qui est partagee entre les differents noeuds, chaque 
noeud conservant cette information sous forme d'un tableau tel que celui illustre 
en figure 11. 

Les niveaux de priorite des messages sont etablis par le moyen 
20 de traitement a partir du service requis. 

En figure 11, on observe un tableau 1100, comportant trois lignes 
1101, 1102 et 1103, chacune des lignes comportant des specifications de 
canaux virtuels 1 1 05 a 1 1 1 0. 

On rappelle ici que chaque canal virtuel est une entity logique 
25 associee & une communication entre deux applications mises en oeuvre par 
deux moyens de traitements associ£s & deux moyens de communication. 

Dans le tableau de la figure 11, on a choisi de repr6senter deux 
canaux virtuels pour chaque niveau de priorite, pour des raisons de clarte. 
Cependant, pour chaque niveau de priorite, le nombre de canaux virtuels peut 
30 varier entre zero a un nombre predetermine. 
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Chacune de ces specifications comporte : 

- une information representative de la taille "specJL" 1111 des 
paquets associes au canal ; 

- une information representative du nombre de paquets a emettre 
5 "spec^CP* 1112 durant I'intervalle de temps primaire considere ; 

- une information representative de la duree "spec_CT 9 1113 de 
I'intervalle de temps primaire considere ; 

- une information representative du niveau de priorite (haut, 
moyen ou bas) "spec _prio" 1114 associe au canal ; 

10 - une information "dynjCP* 1117 representative du nombre de 

paquets reellement emis sur le canal virtuel, pendant I'intervalle de temps 
primaire considere ; 

- une information "dyn_CT % 1118 representative du nombre 
d'intervalles de temps secondaires ecoules pendant rintervalle de temps 

15 primaire considere ; et 

- une information "VCjstate" 1119 representative de Petat dans 
lequel se trouve le canal virtuel, "libre", "acttT ou "endormr (voir figure 12) ; et 

- une information "references" 1120 representative des positions 
(ou references), en memoire, des donnees utilisateura transrnettre. 

20 En outre, les specifications du niveau de priorite basse 

comportent : 

- une information "spec_CPmin" 1115 representative de la valeur 
minimale du nombre de paquets a emettre "spec_CP* 1112 - une information 
"spec_CPmatf % 1116 representative de la valeur maximale du nombre de 

25 paquets a emettre "specJCP* 1112 , ceci afin de permettre de diminuer la 
valeur de "spec_CP" 1112 au cours de Pop6ration 1221 ou de Taugmenter au 
cours de Poperation 1215, dans la limite de ces bomes spec_CPmin 1115 et 
spec_CPmax 1116. 

Enfin, chaque ligne, ou niveau de priority, est affect^e d'une 

30 information "prio_state" 1120 representative de l'6tat dans lequel se trouve 
I'ensemble des canaux virtuels du niveau de priorite considere : lorsqu'au 
niveau de priority consid6r6 ne se trouve aucun canal, le niveau de priority est 
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"/fore", lorsque tous les canaux du niveau de priorite sont dans un etat 
n endormF\ le niveau de priorite est lui-meme dans un etat "endormf\ et dans les 
autres cas, le niveau de priorite est "actif\ 

La table de specifications et de priorites 1100 est constitute en 

5 plagant : 

- en premiere ligne 1101 (niveau de priorite "haut") tous les 
canaux virtuels affect6s a des transmissions en mode connecte, ou "temps reel 
deterministe" (en anglais "predictive real time") ; 

- en deuxieme ligne 1102 (niveau de priorite "moyen") tous les 
10 canaux virtuels affectes a des transmissions en mode connecte temps reel 

garanti (connu sous le nom de temps reel garanti, ou , en anglais, "guaranted 
real time") ; 

- en troisieme ligne 1103 (niveau de priorite "haut") tous les 
canaux virtuels affectes a des transmissions en mode non connecte (connu 

15 sous les noms de "asynchrone" et "elastique", ou , en anglais "elastic"). 

Ainsi, tous les noeuds disposent d'une table de priorite concernant 
le trafic qu'il peut generer, et chacun s'occupe des messages dont il est la 
source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie 
"trafic sortant"). 

20 On observe ici que les parametres de transmission sont 

determines par le moyen de controle de charge a partir du contenu de la table 
de charge. Par consequent, les parametres de transmission associes aux 
canaux virtuels de haute et moyenne priority 1101 et 1102 sont calcules a partir 
d'une connaissance, a priori, sur tout le trafic connecte alors que les 

25 parametres de transmission associes aux canaux virtuels de faible priorite 1 1 03 
sont estim6s h partir d'une connaissance limitee au trafic non-connecte sortant 
du noeud considere. 

La figure 12 repr6sente un organigramme de fonctionnement 
d'emission en modes connecte et non connecte d'un moyen de communication 
30 tel qu'illustr6 en figure 2. Cet organigramme est mis en oeuvre par I'unite 
centrale 206 (figure 2). 
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Le principe du fonctionnement utilise est que Pordre d'emission 
des paquets est base sur le remplissage d'un intervalle de temps primaire IT-P, 
comprenant des intervalles de temps secondaires IT-S. 

A la suite de l'op6ration d'initialisation 1201 par remise a z6ro de 
5 toutes les variables, un test 1202 determine si un intervalle de temps 
secondaire s'est ecoule, le debut d'un intervalle de temps secondare 6tant 
determine a partir de I'horloge temps reel 235. Lorsque le resultat du test 1202 
est positif, au cours d'une operation 1203, I'unite centrale 206 se place en debut 
de la table de specifications et de priorites (figure 11). 

10 Ensuite, au cours d'une operation 1204, rinformation n dyn_CT 

1 1 18 du canal virtuel considere est decrementee. Puis, au cours d'un test 1205, 
I'unite centrale 206 determine si la valeur de rinformation "dyn_CT* 1118 du 
canal virtuel considere est egale a zero, ou non. Lorsque le resultat du test 
1205 est positif, c'est-a-dire a la fin d'un intervalle de temps primaire, au cours 

15 d'un test 1220, I'unite centrale 206 determine si la valeur de rinformation 
"dyn__CP" 1117 est egale a zero, ou non. Le test 1220 correspond done a 
chaque debut d'un nouvel intervalle de temps primaire. 

Lorsque le resultat du test 1220 est n§gatif, au cours d'une 
operation 1221, I'unite centrale 206 gere les priorites de la maniere suivante : 

20 - pour le trafic d6terministe, priorite haute, les paquets non 

transmis durant Tintervalle de temps requis, dont le nombre est egale a la 
valeur de valeur n dyn_CP % 1117, sont supprim6s (perte de paquets) puis, la 
valeur n dyn_CP' 1117 est mise a zero , et 

- pour le trafic garanti, priorite moyenne, les paquets non transmis 
25 durant I'intervalle de temps sont conserves et n dyn_CP % 1117 conserve sa 

valeur, et 

- pour le trafic elastique, priority basse, la bande passante est 
reduite, par decrementation de la valeur n spec_CP* 1112 dans la limite des 
bomes autorisees. 

30 A la suite de I'operation 1221 ou lorsque le resultat du test 1220 

est positif, une operation 1206 est effectu^e. 
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Au cours de I'operation 1206, les specifications et pararnetres de 
transmission sont mis ci jour (voir figure 11): 

- les informations 1111 a 1113 et 1115 a 1116 sont mises a jour a 
la fin de chaque intervalle de temps primaire, en fonction des changements 

5 d'6tat de la table de charge determine par le moyen de controle de charge, 

- la valeur de Information "dyn_CP» 1117 est incrementee de la 
valeur de Tinformation "spec_CP* 1112, 

- la valeur de I'information "dyn_CV 1118 est incrementee de la 
valeur de reformation "spec_CT 1113, 

10 - la valeur de I'information "VC_state" 1119 passe de I'etat 

"endormr a I'etat "actif. 

A la suite de I'operation 1206 ou lorsque le resultat du test 1205 
est negatif, une operation 1207 consiste, pour I'unite centrale 206, a considerer 
le canal virtuel suivant dans la table de specifications et de priorites. 

15 Ensuite, le test 1208 determine si la fin de la table de 

specifications et de priorites a ete depassee, ou non. Lorsque le resultat du test 
1208 est negatif, les operations 1204 a 1207 sont reiterees. Lorsque le resultat 
du test 1208 est positif, c'est-a-dire lorsqu'un intervalle de temps secondaire est 
acheve, un test 1209 determine si la liste des canaux virtuels de niveau de 

20 priorite "hauf possede une information d'etat "prio_state" 1120 a la valeur 
"acf/Y" ou non. Lorsque le resultat du test 1209 est positif, au cours d'une 
operation 1210, Tunite centrale 206 procede a remission du paquet dont le 
remplissage est effectue a partir du champ reference 1120, qui indique la 
position memoire des prochaines donnees a emettre, en mode connects temps 

25 reel deterministe et procede a la mise § jour des specifications du canal virtuel 
permettant remission du paquet consid6r6 : 

- I'information "dynjCR* 1 1 17 est decrements, 

- si I'information "dyn_CP % 1117 est 6gale a zero, la valeur de 
I'information "VC_state" 1119 prend la valeur "endormr et le prochain canal 

30 virtuel du meme niveau de priorite est consid6re et, s'il n'y a aucun autre canal 
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virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio__state" 1 120 prendre la valeur "endormf\ 

Remission du paquet ne se termine que lorsque le prochain noeud 
intermediate a acquitt6 le controle de flux qu'il a oper& sur les donnges dudit 
5 paquet, tel que cela est decrit dans la norme IEEE-1355 et implements par les 
composants ST-C1 01 213 ou 216 et ST-C1 04 209. 

On remarque ainsi que les conflits d'acces aux ressources de 
transmission (les liens de communications) sont detects par le protocole de 
transmission de paquets, par exernple conforme a la norme IEEE-1355, 
10 L'invention permet done de limiter les effets de ces conflits d'acc£s pour 
equitablement repartir I'acces aux ressources entre les differents noeuds du 
reseau, tout en garantissant une qualite de service specifiee par le service 
requis. 

Lorsque le resultat du test 1209 est negatif, un test 1211 
15 determine si la liste des canaux virtuels de niveau de priorite "moyen" possede 
une information d'etat "prio_state" 1120 a la valeur "actif ou non. Lorsque le 
resultat du test 1211 est positif, au cours d'une operation 1212, Punite centrale 
206 procede a remission d'un paquet en mode connecte temps r6el garanti et 
procede a la mise a jour des specifications du canal virtuel permettant 
20 remission du paquet considere : 

- reformation "dyn_CP % 1117 est decrementee, 

- si Tinformation n dyn_CP' 1117 est egale a zero, la valeur de 
Tinformation "VC_state" 1119 prend la valeur "endormf* et le prochain canal 
virtuel du meme niveau de priorite est consid6re et, s'il n'y a aucun autre canal 

25 virtuel de meme niveau de priorit6, le niveau de priorite voit son information 

"prio state" 1120 prendre la valeur "endormr. 

Lorsque le resultat du test 1211 est negatif, un test 1213 

determine si la liste des canaux virtuels de niveau de priorite "bas" poss&de une 

information d'etat "prio_state" 1 120 & la valeur "actif ou non. Lorsque le r6sultat 
30 du test 1213 est positif, au cours d'une op6ration 1214, Tunit6 centrale 206 

procede & remission d'un paquet en mode non connecte et procede a la mise a 
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jour des specifications du canal virtuel permettant remission du paquet 
considere : 

- rinformation "dyn^CR* 1 1 1 7 est decr6mentee, 

- si rinformation "dyn_CP % 1117 est egale a zero, la valeur de 
5 rinformation "VC_state" 1119 prend la valeur "endorm?' et le prochain canal 

virtuel du meme niveau de priorite est consid§re et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1120 prendre la valeur "endormF*. 

Lorsque le resultat du test 1213 est negatif, au cours d'une 
10 operation 1215, I'unite centrale procede a I'analyse de la charge effective du 
reseau. A cet effet, I'unite centrale 206 comptabilise les periodes d'inactivite du 
moyen de communication, pour ajuster le nombre de paquets a emettre par 
canal virtuel, pour le trafic de priorite basse (c'est-a-dire en mode non 
connect^). 

15 En fonction du nombre d'intervalles de temps secondares non 

utilises pour la transmission effective de paquets, la bande passante est accrue, 
par incrementation de la valeur "spec^CP* 1112 dans la limite des bornes 
autorisees. 

Puis, le moyen de communication cesse ses emissions jusqu'a ce 
20 que le resultat du test 1202 devienne positif. 

(.'allocation ou la liberation d'un canal virtuel est effectu6e par 

manipulation: 

- des listes 1101 et 1102, lors de I'execution des differentes 
etapes de gestion d'une connexion illustr6e en figure 4. 

25 - de la liste 1103, lors de la r6ception d'un message 

"SendSyncData_req n ou n SendAsyncData_cfr", par le moyen de 
communication, ernis par le moyen de traitement, jusqu'a transmission 
complete du message. 

Ainsi, le moyen de controle de charge tient compte de la charge 

30 effective sur le r6seau pour repartir les droits d'acces entre les diff6rents 
niveaux de priorite. 





La figure 13 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour Petablissement d'une connexion, 
ce qui correspond, en figure 4, a I'operation 302. 

Le moyen de communication prend en compte la description du 
5 service requis 6tabli par Tapplication ou le peripherique qui 6rnet le message, 
au cours d'une operation 1302. 

Puis, le moyen de communication effectue le choix du canal virtuel 
et du chemin le plus disponible, au cours de I'operation 1304, en faisant usage 
de la table de routage. 

10 Au cours d'un test 1305, le moyen de communication du noeud 

source determine si un chemin a et6 choisi au cours de I'operation 1304 ou 
non. 

Lorsque le resultat du test 1305 est negatif, le moyen de 
communication revendique I'arret de la procedure de mise en place de la 

15 connexion, au cours d'une operation 1306. Lorsque le resultat du test 1305 est 
positif, le moyen de communication effectue le calcul des param6tres de 
transmission, en particulier de la bande passante, de la taille des paquets 
transmis, des taux (frequences demission) de paquets et de priorite de la 
communication correspondant au champ 1111 a 1113 illustres en figure 11, en 

20 faisant usage de la table de charge, au cours d'une operation 1303. 

Puis, au cours d'une operation 1307, le moyen de communication : 

- alloue un canal virtuel en specifiant les parametres de 
transmission precedemment calculus, et 

- fait varier la taille des paquets avec la charge du chemin ainsi 
25 que le taux de paquets sur ledit chemin, et 

- met a jour sa table de charge par I'intermediaire du moyen de 
controle de charge. 

Ensuite, au cours d'une operation 1308, il revendique la poursuite 
de la mise en place de la connexion 
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L'op6ration 302 est alors termin§e. 
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La figure 14 represente un organigramme de determination, par 
un noeud intermediate ou le noeud destinataire, de disponibilite de chemin 
pour I'etablissement d'une connexion, ce qui correspond, en figures 5 et 6, aux 
operations 332 et 372. 

5 Le moyen de communication obtient, d'abord, la description du 

chemin et du service requis associ6s a la nouvelle connexion, en lisant le 
message 251 "sef-up" provenant du noeud source (operation 305), au cours 
d'une operation 1402. 

Puis, le moyen de communication verifie la disponibilite du chemin 
10 en fonction du service requis, au cours de I'operation 1404, en faisant usage de 
la table de routage. 

Au cours d'un test 1405, le moyen de communication du noeud 
consid6re determine si le chemin est disponible au cours de I'operation 1404 ou 
non. 

15 Lorsque le resultat du test 1405 est negatif, le moyen de 

communication revendique la procedure de mise en place de la connexion, au 
cours d'une operation 1406. Lorsque le resultat du test 1405 est positif, le 
moyen de communication effectue le calcul des parametres de transmission, en 
particulier de la bande passante, de la taille des paquets transmis, des taux 

20 (frequence d'emission) de paquet et de priorite de la communication, en faisant 
usage de la table de charge, au cours d'une operation 1403. 

Puis, au cours d'une operation 1407, le moyen de communication 
met a jour sa table de charge par I'intermediaire du moyen de controle de 
charge, ce qui revient a r6server les ressources necessaires a la connexion 
25 envisag6e, puis, au cours d'une operation 1408, il poursuit la mise en place de 
la connexion. A la fin de Tune des operations 1406 ou 1408, I'operation 334 est 
termin6e. 

La mise a jour de la table de charge s'accompagne d'une mise a 
jour des parametres de transmissions associ6s aux canaux virtuels existants 
30 representatifs du trafic sortant pour le noeud consid6re, a travers la valeur des 
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champs 1111 a 1113 pour le trafic connecte et 1111, 1113, 1115, 1116 pour le 
trafic non connecte. 

La figure 15 represente un organigramme de determination, par 
un noeud voisin, de disponibilit6 de chemin pour I'etablissernent d'une 
5 connexion, ce qui correspond, en figure 7, aux operations 413. 

Le moyen de communication obtient, d'abord, la description du 
chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 253 "LinkTabLoad" provenant du noeud source (operation 313), au 
cours d'une operation 1 502. 

10 Ensuite, le moyen de communication effectue le choix des 

parametres de transmission, en particulier de la bande passante, de la taille des 
paquets transmis, des taux de paquet et de priorite de la communication, en 
faisant usage de la table de charge, au cours d'une operation 1503. Puis, au 
cours d'une operation 1504, le moyen de communication met a jour sa table de 

15 charge. A la fin de Poperation 1504, le fonctionnement de mise en place de la 
connexion, par le noeud voisin, est termine. 
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REVEND1CATIONS 

1. Precede de communication sur un reseau, entre des dispositifs 
de communication susceptibles, chacun, de determiner le chemin a faire suivre 

5 a chaque information qu'il a a transmettre, caract6ris6 en ce qu f il comporte : 

- effectuee par chaque dispositif de communication dit "source" 
(801), qui a besoin d f une connexion associee a un chemin, pour effectuer une 
transmission d'information a destination d'un dispositif de communication 
destinataire (802), une operation de demande de connexion (305), au cours de 

10 laquelle, le dispositif de communication source transmet, a destination de 
chaque dispositif de communication dudit chemin, une demande 
d'etabiissement de connexion (251), 

- lorsque I'etablissement de ladite connexion est possible, 
effectuee par au moins le dispositif de communication destinataire, une 

15 operation de transmission (381), a destination du dispositif de communication 
source d'une acceptation de connexion (252), 

- effectuee par le dispositif de communication source, une 
operation de diffusion (313), a tous les dispositifs de communication du r6seau, 
d'une information representative de I'etablissement de la connexion (253), 

20 - effectu6e par chaque dispositif de communication dudit chemin 

(803, 804), a reception de ladite information representative d'etabiissement de 
connexion, une operation de confirmation d'etabiissement (345) de ladite 
^ connexion, et 

- effectuee par chaque dispositif de communication en dehors 
25 dudit chemin (805 a 809), a reception de ladite information representative 

d'6tablissement de connexion, une operation de mise en m<§moire d'une 
information representative de ladite connexion (418). 

2. Procede de communication selon la revendication 1, caract6ris6 
30 en ce que chaque dispositif de communication dudit chemin (803, 804) effectue, 

a reception de la demande d'etabiissement de connexion (251 ), une operation 
de verification de la possibilite d'etabiissement de ladite connexion (1404). 
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3. Procede de communication selon la revendication 2, caract6ris6 
en ce que chaque dispositif de communication dudit chemin (803, 804), lorsque, 
au cours de Poperation de verification (1404), la possibility d'6tablissement de la 

5 connexion a ete verifiee, effectue une operation de reservation de ressources 
necessaires a ladite connexion (1407). 

4. Proc6de de communication selon la revendication 2, caract6rise 
en ce que chaque dispositif de communication dudit chemin (803, 804), lorsque, 

10 au cours de l'op6ration de verification (1404), la possibility d'etablissement de la 
connexion n'est pas v6rifi6e, effectue une operation de transmission (380), a 
destination du dispositif de communication source (801) d'une information 
representative de I'impossibilitfe de la mise en place de la connexion par ledit 
dispositif de communication intermediate. 

15 

5. Procede de communication selon Tune quelconque des 
revendications 1 a 4, caracterise en ce que, lorsque I'etablissement de ladite 
connexion est possible, I'operation de transmission (381), a destination du 
dispositif de communication source, d'une information (252) representative 

20 d'une acceptation de connexion, est effectuee uniquement par le dispositif de 
communication destinataire (802). 

6. Procede de communication selon la revendication 5, caract6ris6 
en ce que, pour transmettre ladite information representative d'une acceptation 

25 de connexion (252), le dispositif de communication destinataire (802) effectue 
une operation de choix de chemin independant du chemin associ6 & la 
connexion en cours d'etablissement. 

7. Proc6d6 de communication selon Tune quelconque des 
30 revendications 1 a 6, caracterise en ce qu'ii comporte, au cours de 

I'etablissement d'une connexion, effectu§ par chaque dispositif de 
communication du reseau (801 a 809), une operation de mise & jour d'une table 
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de charge contenant des informations representatives de charges de liens du 
reseau incorpores dans un chemin associe a une connexion. 

8. Proced6 de communication selon la revendication 7, caracterise 
5 en ce que, pour les dispositifs de communication du reseau intermediaires (803, 

804) et destinataire (802), I'operation de mise a jour de la table de charge est 
effectuee £ reception de la demande d'etablissement de connexion (251). 

9. Procede de communication selon la revendication 8, caracterise 
10 en ce que, pour les dispositifs de communication du reseau situes en dehors du 

chemin associe a la connexion en cours d'etablissement (805 & 809), 
Top6ration de mise a jour de la table de charge est effectuee a reception de 
reformation representative d'etablissement de connexion. 

15 10. Procede de communication selon Tune quelconque des 

revendications 1 a 9, caracterise en ce que I'operation de diffusion (313), a tous 
les dispositifs de communication du reseau (802 a 809), d'une information 
representative de Petablissement de la connexion, operation effectuee par le 
dispositif de communication source (801), est effectuee sur un arbre de 

20 recouvrement du reseau dont au moins la moitie des feuilles sont des dispositifs 
de communication intermediaires ou le dispositif de communication destinataire, 
sur le chemin associe a la connexion. 

11. Proc6de de communication selon Tune quelconque des 
25 revendications 1 a 10, caracterise en ce que la demande d'etablissement de 
connexion (251), 6mise par le dispositif de communication source (801), 
comporte une information representative du service requis pour la transmission 
en mode connects assoctee & ladite connexion. 

30 12. Procede de communication selon Tune quelconque des 

revendications 1 d 11, caracterise en ce que la demande d'etablissement de 
connexion (251), 6mise par le dispositif de communication source (801), 
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comporte une information representative du chemin associe a la connexion en 
cours d'etablissement. 

13. Procede de communication selon Tune quelconque des 
5 revendications 1 a 12, caracterise en ce que chaque dispositif de 

communication (801 a 809) effectue chaque transmission d'information par 
commutation de paquet 

14. Dispositif de communication sur un reseau comportant des 
10 dispositifs de communication (801 a 809) susceptibles, chacun, de determiner 

le chemin a faire suivre a chaque information qu'il a a transmettre, caracterise 

en ce qu'il est adapte, lorsqu'il a besoin d'une connexion associee a un chemin, 

pour effectuer une transmission d'information & destination d'un dispositif de 

communication destinataire : 
15 - a faire transmettre a un moyen de transmission, a destination de 

chaque dispositif de communication (802 a 804) dudit chemin, une information 

de demande d'etablissement de connexion (251 ), et 

- a reception d'une information d'acceptation de connexion (252) 

en provenance du dispositif de communication destinataire, a faire diffuser, par 
20 ledit moyen de transmission, a tous les dispositifs de communication du r6seau 

(802 a 809), une information d'etablissement de la connexion (253). 

15. Dispositif de communication selon la revendication 14, 
caracterise en ce qu'il est adapte, lorsqu'il est le dispositif de communication 

25 destinataire (802) d'une demande d'etablissement de connexion (251), a 
determiner si I'etablissement de ladite connexion est possible et, dans ce cas, a 
faire transmettre, au moyen de transmission, a destination du dispositif de 
communication source (801), une information d'acceptation de connexion (252). 



30 



16. Dispositif de communication selon Tune quelconque des 
revendications 14 ou 15, caracterise en ce qu'il est adapte, lorsqu'il regoit une 
information d'etablissement de la connexion (251 ) et qu'il est situe sur le chemin 
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associe a la connexion en cours d'etablissement, a confirmer I'etablissement de 
ladite connexion. 

17. Dispositif de communication selon Tune quelconque des 
5 revendications 14 a 16, caracterise en ce qu'il est adapte, lorsqu'il regoit une 
information d'etablissement de la connexion (253) et qu'il n'est pas situe sur le 
chemin associe a la connexion en cours d'etablissement, a stacker en m6moire 
une information representative de ladite connexion. 

10 18. Dispositif de communication selon Tune quelconque des 

revendications 14 a 17, caracterise en ce qu'il est adapts, lorsqu'il est un 
dispositif de communication d'un chemin associe a une connexion en cours 
d'etablissement (802 a 804), a verifier la possibility d'etablissement de ladite 
connexion (1404), a reception de la demande d'etablissement de connexion 

15 (251). 

19. Dispositif de communication selon la revendication 18, 
caracterise en ce que, apres avoir verifier la possibility d'etablissement de la 
connexion (1404), ledit dispositif de communication (802 a 804) est adapte a 

20 reserver les ressources dont il dispose et qui sont necessaires a ladite 
connexion. 

20. Dispositif de communication selon la revendication 18, 
caracterise en ce qu'il est adapte, lorsque la possibility d'etablissement de la 

25 connexion n'est pas verifiee, a faire transmettre au moyen de transmission, a 
destination du dispositif de communication source (801), une information 
representative de ('impossibility de la mise en place de la connexion par ledit 
dispositif de communication intermediate. 

30 21. Dispositif de communication selon Tune quelconque des 

revendications 14 a 20, caracterisy en ce que, lorsque I'etablissement de ladite 
connexion est possible, il est adapty a ne faire transmettre au moyen de 
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transmission, a destination du dispositif de communication source (801), 
reformation representative d'une acceptation de connexion (252), uniquement 
lorsqu'il est dispositif de communication destinataire (802). 

22. Dispositif de communication selon la revendication 21, 
caracterise en ce que, pour faire transmettre ladite information representative 
d'une acceptation de connexion (252), le dispositif de communication 
destinataire (802) est adapte a choisir un chemin independamment du chemin 
associ§ a la connexion en cours d'etablissement. 



23. Dispositif de communication selon Tune quelconque des 
revendications 14 a 22, caracteris§ en ce qu'il comporte une memoire (204A) 
adaptee a conserver une table de charge contenant des informations 
representatives de charges de liens du reseau incorpores dans un chemin 

15 associe a une connexion et en ce qu'il est adapte a mettre a jour ladite table de 
charge. 

24. Dispositif de communication selon la revendication 23, 
caracterise en ce qu'il est adapte, lorsqu'il est dispositif de communication 

20 intermediate (803, 804) ou destinataire (802), a mettre a jour la table de charge 
a reception de la demande d'etablissement de connexion (251). 

25. Dispositif de communication selon la revendication 24, 
caracterise en ce qu'il est adapte, lorsqu'il est situe en dehors du chemin 

25 associ6 a la connexion en cours d'etablissement, a mettre a jour la table de 
charge a reception de Tinformation representative d'etablissement de connexion 
(253). 



26. Dispositif de communication selon Tune quelconque des 
30 revendications 14 a 25, caracterise en ce qu'il est adapte a faire diffuser, par le 
moyen de transmission, a destination de tous les dispositifs de communication 
du r6seau (802 a 809), une information representative de P6tablissement de la 
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connexion (253), en faisant suivre, a cette information, un arbre de 
recouvrement du reseau dont au moins la moitie des feuilles sont des dispositifs 
de communication intermediates ou le dispositif de communication destinataire, 
sur le chemin associe a la connexion. 

5 

27. Dispositif de communication selon Tune quelconque des 
revendications 14 a 26, caracterise en ce qu'il est adapte a ce que la demande 
d'etablissement de connexion (251), 6mise par le dispositif de communication 
source (801), comporte une information representative du service requis pour la 

10 transmission en mode connecte associee a ladite connexion. 

28. Dispositif de communication selon Tune quelconque des 
revendications 14 a 27, caracterise en ce qu'il est adapte a ce que la demande 
d'etablissement de connexion (251), 6mise par le dispositif de communication 

15 source (801), comporte une information representative du chemin associe a la 
connexion en cours d'etablissement. 



n 



29. Dispositif de communication selon Tune quelconque des 
revendications 14 a 28, caracterise en ce qu'il est adapte a fonctionner sur un 

20 reseau a commutation de paquet. 

30. Ordinateur, caracterise en ce qu'il comporte un dispositif de 
communication selon I'une quelconque des revendications 14 a 29 

25 31. Camera, caracterisee en ce qu'elle comporte un dispositif de 

communication selon I'une quelconque des revendications 14 a 29. 

32. TelScopieur, caracterise en ce qu'il comporte un dispositif de 
communication selon I'une quelconque des revendications 14 a 29. 

30 

33. Appareil photographique, caracterise en ce qu'il comporte un 
dispositif de communication selon Tune quelconque des revendications 14 a 29. 
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34. Tel6viseur, caracteris6 en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 14 a 29. 

35. Imprirnante, caracteris6e en ce qu'elle comporte un dispositif 
de communication selon Tune quelconque des revendications 14 a 29. 

36. Scanner, caracteris6 en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 14 a 29. 

37. Lecteur audio/video, caracterise en ce qu'il comporte un 
dispositif de communication selon Tune quelconque des revendications 14 a 29. 
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